Jsou opravdu DB komponenty tak spatne?
Otázka od: Karel Kral
20. 8. 2004 8:37
Ahoj,
MS SQL 2000/ADO/D7 Pro, DB komponenty DevExpress
Pokud se k tomu chcete nekdo vyjadrit, budu rad:
Potrebuji editovat jednoduchy ciselnik, spise velke mnozstvi ruznych
ciselniku. Protoze ctu tuhle konferenci uz leta, vzdy jsem provadel
editaci zaznamu pomoci ADO tak, ze jsem si natahl data z aktualniho
zaznamu gridu - datasetu do zvlastniho formulare - normalnich (ne DB)
komponent. Pak jsem delal update dat pomoci TADOCommand a SP. Je s tim
neuveritelne mnoho prace a psani - pretahnout data do editacnich
komponent, pak je zase transformovat zpet atd.
Pak jsem se poradne podival pomoci SQL profileru na to, co vlastne ADO
posila za SQL prikazy pri pouziti DB komponent. A zjistil jsem, ze se
chova _velmi_ rozumne, pokud ma tabulka PK. Takze jsem vyzkousel pouzit
na editacnim formulari primo DB komponenty a na konci editace udelat
DataSet.Post nebo DataSet.Cancel podle toho, jak skonci editace.
Naprosto bez problemu a bez prace.
V takovem pripade nechapu, v cem by mohlo byt na zavadu editovat zaznam
takto. Jediny problem vidim v tom, kdyz dva uzivatele zmeni zaroven
stejne _pole_ ve stejnem zaznamu. To pak ADO neni schopno zaznam
aktualizovat a kdo ulozil prvni, ten vyhral. To se ale da resit
rezervaci zaznamu pred editaci tak, aby nemohli stejny zaznam editovat
dva uzivatele. Konecne - rezervaci zaznamu potrebuju i pri editaci v
normalnich komponentach.
jeste shrnuti:
DB komponenty:
+ mnohem mensi pracnost (3x az 4x)
- potrebuji prava update primo editovane tabulky
Ne-DB komponenty
+ stored procedura pro ulozeni dat neni zavisla na pravach uzivatele k
tabulce
+ mam vetsi volnost k tomu, co zobrazit na formulari a jak validovat data
- desne pracne
Talze muj dojem: NEpouzit pro jednoduche veci DB komponenty je zbytecne
a velmi velmi pracne, pro slozite veci je to uz na zvazenou.
--
______________________________________________________
Karel Kral, vedouci odd. IT / IT manager
Purus, s.r.o., Cezavy 627, 664 56 Blucina, CZ
Tel: 547 235 000, 602 552 432, Fax: 547 231 203
E-Mail: mailto:kral@purus.cz, WWW: http://www.purus.cz
______________________________________________________
Odpovedá: info@gastrocentrum.cz
20. 8. 2004 9:41
> Talze muj dojem: NEpouzit pro jednoduche veci DB komponenty je zbytecne
> a velmi velmi pracne, pro slozite veci je to uz na zvazenou.
Ahoj
Mam podobny pocit o pracnosti, presto jsem novy projekt zacal s koncepci
NON-DB
Protoze ciselniku je take dost (restauracni system) tak si snazim
"zjednodusit " tim ze mam vytvorenu tridu zakladniho ciselniku , jednoh
univerzalniho formu a vytvarim objekty konkretnich cisleniku dedenych z
toho zakladniho a prirazuji je na ten form.
S pozdravem Heinisch Jiri
www.gastrocentrum.cz
www.drnholec.cz
Odpovedá: Slavomir Skopalik
20. 8. 2004 9:42
Ja to takto delam na IB/FB jiz mnoho let.
Na ib/fb neni pri vkladani SP nutna, jelikoz lze vkladat do view (pomoci
trigru si delat poradek),
pripadne mam k dispozici before update triger, kde mam vsechny potrebne
validace.
Slavek
> V takovem pripade nechapu, v cem by mohlo byt na zavadu
> editovat zaznam
> takto. Jediny problem vidim v tom, kdyz dva uzivatele zmeni zaroven
> stejne _pole_ ve stejnem zaznamu. To pak ADO neni schopno zaznam
> aktualizovat a kdo ulozil prvni, ten vyhral. To se ale da resit
> rezervaci zaznamu pred editaci tak, aby nemohli stejny zaznam
> editovat
> dva uzivatele. Konecne - rezervaci zaznamu potrebuju i pri editaci v
> normalnich komponentach.
>
> jeste shrnuti:
>
> DB komponenty:
> + mnohem mensi pracnost (3x az 4x)
> - potrebuji prava update primo editovane tabulky
>
> Ne-DB komponenty
> + stored procedura pro ulozeni dat neni zavisla na pravach uzivatele k
> tabulce
> + mam vetsi volnost k tomu, co zobrazit na formulari a jak validovat
> + data
> - desne pracne
>
> Talze muj dojem: NEpouzit pro jednoduche veci DB komponenty
> je zbytecne
> a velmi velmi pracne, pro slozite veci je to uz na zvazenou.
Odpovedá: Zbysek Hlinka
20. 8. 2004 9:16
> -----Original Message-----
> From: delphi-l-owner@clexpert.cz
> [mailto:delphi-l-owner@clexpert.cz] On Behalf Of Karel Kral
>
> Potrebuji editovat jednoduchy ciselnik, spise velke mnozstvi
> ruznych ciselniku. Protoze ctu tuhle konferenci uz leta, vzdy
> jsem provadel editaci zaznamu pomoci ADO tak, ze jsem si
> natahl data z aktualniho zaznamu gridu - datasetu do
> zvlastniho formulare - normalnich (ne DB) komponent. Pak jsem
> delal update dat pomoci TADOCommand a SP. Je s tim
> neuveritelne mnoho prace a psani - pretahnout data do
> editacnich komponent, pak je zase transformovat zpet atd.
>
> DB komponenty:
> + mnohem mensi pracnost (3x az 4x)
> - potrebuji prava update primo editovane tabulky
>
> Ne-DB komponenty
> + stored procedura pro ulozeni dat neni zavisla na pravach uzivatele k
> tabulce
> + mam vetsi volnost k tomu, co zobrazit na formulari a jak validovat
> + data
> - desne pracne
Muj nazor a zkusenosti (delal jsem obema zpusoby) jsou takoveto. DBaware
komponenty nejsou spatne z principu, ale za zcela spatny povazuju takovy
zpusob pouziti, kdy jsou komponenty pouzity na propojeni s "zivym" zaznamem.
Ostatne se to odrazi na souctu tvych plusu a minusu. Pak jen zalezi na tom,
jake pridelis vahy jednotlivym bodum. Pokud pridelis nejvetsi vahu
pracnosti, pak zvitezi bod 1. Jen upozornuju, ze se jedna o pracnost na
zacatku, ale neni tam videt pracnost nasledne udrzby. Tak, jak je to reseno
v Delphi, to IMHO neni dobre.
Pro ilustraci uvedu, jak to lze resit v .NET (myslim, ze to bude dost poucne
pro ty, kteri to jeste nevedi). Tam je dataset ZASADNE odpojeny od zdroje
dat. To mi uz z principu umoznuje mit nad tokem dat naprosty dohled a pouzit
zpusob ulozeni takovy, ktery je pro danou situaci nejvhodnejsi.
V .NET nejsou zadne specialni DBaware komponenty. Kazda komponenta ma vsak
pristup k vlastnosti DataBindings, ke ktere mohu pripojit nejake pole z
datasetu. Takze navrh muze vypadat napriklad takto. Navrhnu si dataset,
naplnim ho daty (napriklad z databaze), priradim si k nejake vhodne
vlastnosti komponenty pole z datasetu a edituju. Kdyz je hotovo, mohu se
rozhodnout co dal. Muzu vratit puvodni stav (dataset si udrzuje puvodni
hodnoty), muzu to poslat pres jednu komponentu do databaze (obdobne jako v
Delphi, s tim rozdilem, ze zde mohu zautomatizovat i ukladani pres SP), nebo
tabulku z datasetu poslu rucne do SP (vyctu pole a dosadim je do parametru
SP).
MS VS (pozor, nikoliv D8!!!) ma udelatka, ktera vytvareji k navrzenemu
datasetu kod, takze pak k jednotlivym polim mohu pristupovat "nativne" (tedy
bez indexovani, to se deje uvnitr). To do znacne miry usnadnuje praci, pri
zachovani dohledu nad tim, co se s daty deje. .NET pritom umoznuje
dostatecne kvalitni validaci i v pripade, ze spojim pole s komponentou.
Asi tak nejak. Tim jsem v podstate i vysvetlil jeden z hlavnich duvodu, proc
uz s Win32 Delphi nechci delat. 
S pozdravem
Zbysek Hlinka
E-mail: hlinka zavin. hlinka.cz
Phone: +420 603 551 282
Odpovedá: Lstiburek Pavel
20. 8. 2004 9:40
Ahoj,
add) rezervace
Reseni problemu "rezervace" dat na DB serveru obecne je dosti iluzorni.
Zalezi na typu ulohy, pro dostatecne slozite systemy (vzjemne zavislost
mezi datovymi elementy) to prakicky nelze a je nutno vyuzivat nastroju
DB serveru.
add) vyuziti DB komponent
Je tam jeden problem, vlastni "rezervace" zaznamu neni dostacujici,
pred editaci je nutno provest refresh editovaneho zaznamu
a vsech pouzitych ciselniku a to tyto komponenty nedelaji.
Pokud netrvame na "rezervaci", ale staci, ze nelze opravit zaznam,
ktery opravil nekdo jiny, je na MSSQL nejlepsim reseni sloupec
typu "timestamp".
add) pristupova prava
GRANT pristupovych prav pro uzivatele primo na data neni
prilis doporuceni hodnym zpusobem reseni bezpecnosti.
Znamena to, ze pokud uzivatel zna jmeno uzivatele a heslo,
tak muze pristoupit k datum primo mimo aplikci (zkus si pohrat s
EXCELem nebo MSQUERY). To, ale znamena, ze veskera
business logika musi byt ulozena v datovych elementech
databaze a to je pomerne slozite.
Zaver je urcite spravny, na jednoduche veci jsou DB komponenty
naprosto idealni (zejmena pokud nepozadujeme bezpecnost).
Na druhou stranu vytvorit si pro tridu uloh, kterou programuji
vhodny framework, ktery umozni tuto praci automatizovat je
pomerne jednoduche a potom se rozdily v pracnosti do znacne miry stiraji.
Ja pouzivam DB komponenty jako editacni elementy (neni nutno
programovat prenost do editacnich komponent), ale vlastni
update a insert provadim ulozenou procedurou. Proceduru generuji
jednoduchou SP na strane serveru, tak, ze nazvy parametru SP
odpovidaji nazvum DataField editovaneho DataSetu (vzdy view
a to se da naprogramovat v komponente jednoduse jednim cyklem),
tuto hrubou formu SP uz jen rucne upravim o business logiku.
Vsechny kroky ridi velmi jednoducha vizualni komponenta s tlacitky
(ty by tam stejne musely byt) a par udalosti typu befor a after.
Podobnym zpusobem je vytvorena komponenta pro editaci child
zaznamu (blahorecim Borlandum D5 a MS za podporu XML - sice
bidnou, ale dostacujici).
Primo DB komponenty vyuzivam pouze pro editaci ciselniku,
to v nasi aplikaci delaji pouze uzivatele s IQ, kteri si jsou vedomi
co zpusobi. A hlavnim duvodem je lenost psat pro kazdy z cca 100
ciselniku ulozenou proceduru a view.
> From: Karel Kral [mailto:kralkonf@purus.cz]
> Sent: Friday, August 20, 2004 9:38 AM
> MS SQL 2000/ADO/D7 Pro, DB komponenty DevExpress
>
> Pokud se k tomu chcete nekdo vyjadrit, budu rad:
>
> Potrebuji editovat jednoduchy ciselnik, spise velke mnozstvi ruznych
> ciselniku. Protoze ctu tuhle konferenci uz leta, vzdy jsem provadel
> editaci zaznamu pomoci ADO tak, ze jsem si natahl data z aktualniho
> zaznamu gridu - datasetu do zvlastniho formulare - normalnich (ne DB)
> komponent. Pak jsem delal update dat pomoci TADOCommand a SP.
> Je s tim
> neuveritelne mnoho prace a psani - pretahnout data do editacnich
> komponent, pak je zase transformovat zpet atd.
>
> Pak jsem se poradne podival pomoci SQL profileru na to, co
> vlastne ADO
> posila za SQL prikazy pri pouziti DB komponent. A zjistil jsem, ze se
> chova _velmi_ rozumne, pokud ma tabulka PK. Takze jsem
> vyzkousel pouzit
> na editacnim formulari primo DB komponenty a na konci editace udelat
> DataSet.Post nebo DataSet.Cancel podle toho, jak skonci editace.
> Naprosto bez problemu a bez prace.
>
> V takovem pripade nechapu, v cem by mohlo byt na zavadu
> editovat zaznam
> takto. Jediny problem vidim v tom, kdyz dva uzivatele zmeni zaroven
> stejne _pole_ ve stejnem zaznamu. To pak ADO neni schopno zaznam
> aktualizovat a kdo ulozil prvni, ten vyhral. To se ale da resit
> rezervaci zaznamu pred editaci tak, aby nemohli stejny zaznam
> editovat
> dva uzivatele. Konecne - rezervaci zaznamu potrebuju i pri editaci v
> normalnich komponentach.
>
> jeste shrnuti:
>
> DB komponenty:
> + mnohem mensi pracnost (3x az 4x)
> - potrebuji prava update primo editovane tabulky
>
> Ne-DB komponenty
> + stored procedura pro ulozeni dat neni zavisla na pravach
> uzivatele k
> tabulce
> + mam vetsi volnost k tomu, co zobrazit na formulari a jak
> validovat data
> - desne pracne
>
> Talze muj dojem: NEpouzit pro jednoduche veci DB komponenty
> je zbytecne
> a velmi velmi pracne, pro slozite veci je to uz na zvazenou.
Odpovedá: Petr Vones
20. 8. 2004 9:49
From: "Zbysek Hlinka" <konference@hlinka.cz>
> Pro ilustraci uvedu, jak to lze resit v .NET (myslim, ze to bude dost poucne
> pro ty, kteri to jeste nevedi). Tam je dataset ZASADNE odpojeny od zdroje
> dat. To mi uz z principu umoznuje mit nad tokem dat naprosty dohled a pouzit
> zpusob ulozeni takovy, ktery je pro danou situaci nejvhodnejsi.
Coz je shodne s pouzitim TClientDataSetu v Delphi.
> MS VS (pozor, nikoliv D8!!!) ma udelatka, ktera vytvareji k navrzenemu
> datasetu kod, takze pak k jednotlivym polim mohu pristupovat "nativne" (tedy
Pokud tim myslis typed datasety tak si je muzes vygenerovat i v Delphi.NET, v
nejhorsim pomoci xsd.exe a predanim prislusneho CodeDom providera.
Petr Vones
Odpovedá: Zbysek Hlinka
20. 8. 2004 10:20
> -----Original Message-----
> From: delphi-l-owner@clexpert.cz
> [mailto:delphi-l-owner@clexpert.cz] On Behalf Of Petr Vones
> Sent: Friday, August 20, 2004 10:50 AM
>
> > MS VS (pozor, nikoliv D8!!!) ma udelatka, ktera vytvareji k
> navrzenemu
> > datasetu kod, takze pak k jednotlivym polim mohu
> pristupovat "nativne"
> > (tedy
>
> Pokud tim myslis typed datasety tak si je muzes vygenerovat i
> v Delphi.NET, v nejhorsim pomoci xsd.exe a predanim
> prislusneho CodeDom providera.
Myslim typove datasety, a myslim take to, ze VS k takovemu navrhu umi
vygenerovat i zdrojovy kod novych trid, ktere prekryvaji DataSet, DataTable
a DataRow, pomoci ktereho mohu vyrazne pohodlneji pristupovat k datum ve
strukture. V D8 jsem nic takoveho nenasel, a ani me nikdo nevyvedl z omylu,
kdyz jsem to zminoval v recenzi.
S pozdravem
Zbysek Hlinka
E-mail: hlinka zavin. hlinka.cz
Phone: +420 603 551 282
Odpovedá: Petr Vones
20. 8. 2004 10:14
From: "Zbysek Hlinka" <konference@hlinka.cz>
> Myslim typove datasety, a myslim take to, ze VS k takovemu navrhu umi
> vygenerovat i zdrojovy kod novych trid, ktere prekryvaji DataSet, DataTable
> a DataRow, pomoci ktereho mohu vyrazne pohodlneji pristupovat k datum ve
> strukture. V D8 jsem nic takoveho nenasel, a ani me nikdo nevyvedl z omylu,
> kdyz jsem to zminoval v recenzi.
D8 IDE to asi opravdu neumi, nicmene pokud mas XSD schema tak by to slo tou
cestou pres xsd.exe a codedom providera. Tim nechci rict, ze by snad nekdo
normalni mel neco takoveho v praxi delat 
Petr Vones